A backend system, such as a server system for serving one or more business applications, typically provides metadata to describe a set of business data. Metadata can have different versions depending on the set of business data being handled by the backend system.
There are three classes of metadata, when considered from an “owner” point of view: (1) Metadata that is owned by a backend system; (2) metadata that establishes a connection between the metadata of two or more backend systems, and hence is not “owned” by any of the backend systems; and (3) metadata which is owned by one of the backend systems but refers to metadata of another backend system.
However, handling of metadata that is not restricted to a single system, connection, or server, (herein collectively referred to as a “system”), has heretofore not been addressed. For instance, an enterprise resource planning (ERP) and a customer relationship management (CRM) system both have their own metadata for search. When defining a search for a callback scenario, for example, such as “Find all CRM customers who have purchased ERP material 4711,” the metadata that is required uses ERP and CRM metadata at the same time. This cross-system metadata has to be delivered, and the versioning thereof has to be handled.
Previously, a hub system had to manage various versions of the backend system. These backend system versions are a separate dimension from the hub releases, which therefore multiply the versions to be handled. Further, the hub has to follow a much higher frequency of delivery in order to satisfy every backend system version. Accordingly, the hub becomes highly dependent of the backend system releases, and vice versa.
Another problem is versioning of metadata in a hub and backend system landscape. While each backend system can automatically upgrade its connecting metadata, connections can still be incomplete. Consider backend system “System A”, versions 1.0 and 2.0, and backend system “System B.” Initially a connection “A1.0<->B1.0” is established and delivered with the both backend systems. An upgrade of A automatically leads to a new connecting metadata “A2.0<->B1.0”, and vice versa, when the new backend system version is linked to the hub system. But the connecting metadata “A2.0<->B2.0” does not emerge automatically.